最佳实践

稳定性实践概述

基于上述的稳定性因素风险，在整体层面，需考虑。

  • 云平台相关软件选型：从平台系统的容错能力、系统自恢复能力、软件Bug等层面整体评估云平台软件的可用性，一般是在项目初级进行可接受性验证测试确认相关能力。
  • 硬件：需选择硬件品控高及兼容性好的硬件及配件作为基础平台的选型。项目实践中有遇到过基本的网卡采用便宜不兼容的光模块带来金融核心业务的长时间波动，严重影响业务的连续性。
  • 方案：从最底层的硬件到最上层的业务各个层级均规划高可用架构，例如，网络堆叠、网络Bond、存储多副本，存储多路径，业务高可用。有预算的情况，可以考虑投入资源建设双活或两地三中心架构。在灾备层面考虑云主机灾备、业务灾备、应用灾备、双活容灾等整体方案。须知，有效备份才是数据安全保命的根本。需要规划定期执行灾备有效性检查、故障演练等确保备份有效。
  • 负载：利用平台的实时监控报警机制，配置实时有效终端（邮箱、钉钉、短信等形式）接收平台重要告警，对平台及环境执行日常巡检，发现负载风险或容量风险，尽快扩容。
  • 人员：内部指定规范的运维故障管理制度和更管控流程，提供运维变更操作的标准知识库及标准作业方法。对人员进行定期培训，使其掌握云计算平台的基础操作及日常基本使用规范，理解并运用运维风险检查清单的风险操作说明，按照标准程序执行相关变更，防止误操作行为的发生。
  • 环境：对基础设施的硬件环境配置安全防护、网络隔离、取消公网映射、强密码控制、权限控制等，对平台资源配置防火墙、安全组、权限账户管理进行隔离防护。对数据中心基础环境的电力、温湿度、网络的SLA提供可靠性保障。

常规稳定性实践

服务器硬件：

  • CPU：保证服务器与机房散热，灰尘等，以及关注CPU负载，以及禁止CPU超频，避免因为CPU过热导致物理机宕机
  • RAID：
    • 使用具有断电保护的RAID卡，避免cache数据丢失。
    • 配置1/5/10等高冗余数据保护
    • 配置raid为Write-through，避免断电内存数据丢失。
    • 建议采购独立RAID卡，不建议使用板载RAID卡，断电后可能导致无法正确进入系统。
    • 未配置RAID卡机器断电后可能无法进入系统。
  • 硬盘：
    • 系统盘均推荐使用SSD，能够为数据库提供较高的IOPS和带宽。
    • 针对同一节点下不同角色复用场景均建议使用SSD作为系统盘。
    • 针对不同方案进行分别配比，机械硬盘需考虑尺寸和容量，本地存储中需折算RAID后的实际有效容量，同时还需规划镜像仓库的容量，推荐镜像仓库的容量为2T，企业存储中需折算为三副本后的有效容量，生产环境必须三副本。
    • SSD作为缓存盘时必须DWPD大于3。
    • SSD作为系统盘大小推荐大于400-600G。
    • SSD寿命到期前及时更换。
  • 电源：使用双电源，接两路点，提供物理机电源冗余性。
  • 推荐使用Intel 系列网卡，避免使用博通网卡，存在延迟高，带宽低等问题。

网络：

  • 管理网络可采用千兆网络，网络资源充足的场景，管理网络也可以采用万兆网络。
  • 管理网络、业务网络建议在物理链路层面进行隔离，同时均采用双链路配置bond，bond模式优先考虑链路聚合模式，进一步提高网络带宽以及网络可靠性。
  • 计算节点内网卡建议相同型号卡可以设置跨物理网卡做bond配置，达到物理冗余。
  • 在特殊情况下，管理网卡、业务网卡即使均为单个物理网口，也都建议配置bond，进行网卡名称归一化配置。
  • 交换机配置堆叠，防止单点故障，提高网络稳定性。

云平台：

  • 双管理节点。
  • 云主机配置Nerverstop。
  • 使用灾备，CDP等高级功能保证数据安全。
  • 禁止在物理机安装非ZStack Cloud云平台软件，存在未知风险以及不兼容等不可控问题
  • 生产环境禁止内存，主存储超分。CPU超分率推荐1:4，内存超分率推荐1:1，主存储超分率1:1
  • 内存保留：本地存储，集中式存储推荐物理机内存保留20G，超融合每个OSD预留5G，例如8块OSD40G与系统16G，共计预留56G。
  • 资源预留：
    • 主存储预留200G
    • 镜像服务器预留200G
  • 产品版本：保持最新稳定版本，解决遗留问题以及相关组件漏洞。

操作系统：

  • CPU利用率＞50%需注意，CPU利用率＞70%需关切。
  • 内存利用率＞60%需注意，内存利用率＞80%需关切。
  • 磁盘利用率＞80%需注意，磁盘延迟＞10ms需注意。
  • 物理网络延迟＞1ms，需关注硬件。
  • 驱动版本：更新硬件厂家推荐稳定版本。

人员：

  • 加强人员安全意识培训，建立内部运维规范，提供运维变更方法，规范动作执行避免误操作。
  • 运维人员权限分级，避免权限过大导致一些列问题。
  • 灾备演练，故障演练，安全演练加强运维人员能力。

容量稳定性策略

容量管理在日常云计算管理中经常容易被忽略，但容量使用带来的业务连续性问题不能被忽略，会导致业务暂停，而且在容量不能及时扩容的场景会非常麻烦，无法选择可以删除的资源来释放容量。

日常遇到的问题有：

  • 物理机系统盘容量使用爆满会导致该物理机上所有业务云主机暂停。
  • 云主机系统盘或数据盘容量使用爆满会导致该云主机暂停。
  • 主存储容量写满会导致使用该存储的所有业务云主机暂停。
  • 管理节点系统盘或数据盘写满会导致管理节点服务不可使用，管理节点UI界面无法正常访问。
  • 持续的定时快照任务会使得存储容量快速增长，而不受控制，不仅容量存在写爆的风险，而且大量快照会使得云主机的性能下降，甚至会导致云主机业务出现IO 错误。
  • Ceph分布式存储单个OSD容量写入超过90%，会导致整个Ceph存储池触发写保护，所有使用该存储池的业务出现IO错误。
  • Ceph存储池整体写入量超过70%，在伪随机的请求分布后，OSD之间的使用量会存在10%的差值，个别OSD可能会接近90%的阈值上限，需尽快扩容或释放不必要的容量。
  • 为保障业务的持续稳定运行，对容量的持续有效监控是必要的。云平台支持对上述风险的监控报警，建议提前设置80%作为容量监控的实践，发现风险提前介入，避免发生意外故障。

注意事项

  • 物理机hostname及/etc/hosts 内容不得随意修改，如果同时作为Ceph存储节点，修改后会导致存储服务异常，业务中断。
  • 物理机iptables规则不得随意调整，否则会导致网络中断、监控异常、服务异常等问题。
  • 物理机网卡名称不得随意修改，修改可能导致网络中断，如果同时作为Ceph存储节点，则会导致存储服务异常，业务中断。
  • 物理机系统禁止在断电测试之外的强制暴力断电，包含IPMI带外管理界面的冷关机，意外断电可能会导致内存中没有落入硬盘的数据丢失，进而引起系统损坏，需要额外修复系统。系统关机需严格遵守标准流程关闭。
  • 物理机系统/etc/目录下配置文件禁止随意修改，修改可能导致服务异常、网络中断。
  • 生产环境避免使用软Raid。

results matching ""

    No results matching ""